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(57) Abstract 

A method and system for managing a purchase request in a Daf;i Center system. The Data Center system receives ;) purchase request 
from plurality of potential buyers. The Data Center system provides access to a plutaltty of lemoxly incnted vehicle dealer or deafer 
groups. The dialer accesses the purchase request awl displays its details. The dealer may then assign the handling o*' the purchase request to 

a .saiespeisun. The salesperson ascertains a purchase request property such as an immediate buyer, based upon the purchase request details, 
and the salesperson acts, iicordin^lj hJsid uroii tie ascertained purchase requts- property. The Data Center system further contains one 
or more action response modules which assist the use;' act in response to the nscertainsd purchase request property. Titus, the Data Center 
system assists the dealership to efficiently act upon a purchase, request. 
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REAL TIME VEHICLE PURCHASE REQUEST MANAGEMENT 
METHOD AMD SYSTEM 



Background 

Field 

The present invention is related to systems and methods for conducting business transactions. More 
particularly, this invention relates to a seller managing potential customers purchase requests. 
Description of the Related Art 

The global economy has made the business of selling mere competitive than ever. Businesses that do not 
maximize customer satisfaction and profitability may not snrvive in today's markets. Businesses are therefore demanding 
tools afid methods to provide a competitive edge. 

In a conventional sales scenario, a potential customer initiates a purchasing process by visiting a dealership. The 
customer 0137 make several preliminary visits before making his or her purchasing intent known to the dealer. The 
customer's manifestation of the purchasing intent to the dealer may be ecjtiivaienl to the dealer receiving a parcfisse 
request. 

In the conventional vehicle dealership setting, namely, a car dealer, the salesperson works on a commission bssfs, 
The salesperson's income is directly related to a vehicle's sales pnce and the number of vehicle sales. Thus, the 
salesperson will want to be credited for the sale ant! earn the resulting commission. The cfinvemkmi vehicle dealership 
setting may not foster efficient cooperation between the sales staff. Thus, the purchaser may experience frustration and 
unpleasantness with the purchasing experience. 

For example, once a customer is approached by a salesperson, any resulting sale is credited to the salesperson. 
As far bs the purchasing process, the salesperson may be the purchaser's sole dealership contact. The other sales staff 
may lis - eluctant to assist either the salesperson or the purchaser in consummating the sale. This inefficiency may 
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ultimately result in customer frustration and a iost sale for the dealership. In this setting, the dealership operates 
inefficiently in processing the purchase request. 

Multi-franchise dealerships are becoming common in today's vehicle rnsiketDisce. A multi-franchise dealership 
seils more than one make of vehicle from a single location and a single sales staff. With the multi-franchise dealer, not all 
members of the sales staff are equally knowledgeable and qualified to sell all vehicle makes sold by the dealership. 

In the multi-franchise dealership, a purchaser looking for one make of vehicle may be approached by -a 
salesperson less qualified to assist ths purchaser in making the purchase of the desired vehicle than other salespersons in 
the same dealership. The salesperson may not possess the required product knowledge, or may be too busy to provide the 
necessary assistance. But, the lack of cooperation between -he sales staff, inhibits the purchaser from receiving better 
assistance. Thus, customer satisfaction is not maximized, and the purchaser may experience unnecessary frustration. 
This results in dealership inefficiencies and potential last sales. 

Su mmary 

The present invention is related to systems and methods for conducting transactions utilizing networked 
computers. More particularly, this invention relates to a seller managing potential customers purchase requests. 

In conducting a commercial transaction such as the sale cf a vehicle, a Data Center system facilitates the 
formulation and submission of a purchase request. The Data Center system provides at least a first user web page 
accessible by a potential buyer. The potential buyer accesses this web page and provides the necessary information 
needed ta generate a purchase request. The buyer provided information is then used to create a new vehicle purchase 
request record or 8 used vehicle purchase request record. 

t3ch participating seller may be assigned an exclusive database region in a Data Center system database, in 
another embodiment, a seller record m3v advantageously exist for each seller, and the seller record contains information 
associated with the particular seller. For example, the seller record can contain or point tc the seller's purchase request 
records. Here, the collection of ell records associated with the seller advantageously comprises a virtual exclusive 
database region in the Data Center system database. The Data Center system database further contains information 
regarding, far example, sellers, exclusive seller regions,, and available products. 

When a potential buyer submits either a new vehicle purchase request or a used vehicle purchase request, the 
Uat3 Center system invokes program modules such as, by way of example, a buyer access modulB, to create an 
appropriate purchase request record. Moreover, the Data Center system identifies and notifies an appropriate seller of the 
purchase request. In one embodiment, the purchase request record is stored in the appropriate seller's exclusive database 
region. In another embodiment, the seller record may advantageously point to the purchase request record. Thus, the 
seller immediately becomes aware of the purchase request upon the purchase request's creation. 

The present invention facilitates a real time purchase request management by a seller. The Data Center system 
provides the seller at least a second HTML page with which to directly access its exclusive database region. The direct 
and immediate access enables the seller to be immediately notified .of newly created purchase requests along with any 

-2- 



WO 06/42558 



PCT/US0W00962 



other seller information stored in its exclusive database region. The immediate notification and direct database access 
enables the seller to efficiently manage its purchase requests. 

A seller is able to immediately determine a purchase request priority upon viewing the purchase request record. 
For example, the seiier can display the purchase request record contents and determine the purchase request's priority. 
The purchase request priority enables the seller to efficiently set upon the purchase request it! a timely manner. 

Aiso, for any purchase request the seller may associate a purchase request task such as, by way of example, 
making the initial buyer contact, and calling the potential buyer to provide a haggle-free pries quote, to a purchase request 
and assign the task to a user associated with the seiier. Thus., the invention advantageously provides for the assignment of 
separate tasks to individuals most capable of efficiently acting on the purchase request. 

The Data Center system initially assigns a status of "new" to each submitted purchass request. The seller may 
subsequently change the status by assigning a different status such as, by way of example, "quoted", ''pending", and 
"sold", to the purchase request. This enables the seller to efficiently manage its purchase requests by appropriately 
determining what action tc take based on the purchase request status. 

Thus, in contrast to conventional systems, the seller is able to efficiently manage its purchasa requests by 
assigning -asks to capable salespersons. Moreover, the seiier may efficiently and 3dvant3geously act upon the purchase 
request based upon the current purchase request status. This increases customer satisfaction and the likelihood of 
consummating a vehicie sale. 

Brief Description of the Drawings 
These and other aspects, advantages, and novel features of the invention wit! become apparent upon reading the 
following detailed descriptor? and upon reference to accompanying drawings in which: 

Figure 1 is a system block diagram illustrating an embodiment of the overall network architecture of the 

invention; 

Figure 2 is a representation of one embodiment of an exclusive dealer regions record of the invention; 
Figure 3 is a representation of one embodiment of a dealer record of the invention; 
Figure 4 is a representation of one embodiment of a new vehicle record of the invention; 
Figure 5 is a representation of one embodiment of a used vehicle record of the invention; 
figure 6 is a high level block diagram illustrating one embodiment of a Data Center server system architecture of 
the invention; 

Figure 7 is a representation of one embodiment of a new vehicle purchase request record of the invention; 

Figure 8 is a representation of one embodiment of a used vehicie purchase request record of the invention; 

Figure 9 is a block diagram illustrating one embodiment of a communication between a buyer, a seller, and 
components of a Data Center system; 

Figure 10 is a flow chart illustrating a real time new vehicle purchase request submission and delivery process in 
accordance with one embodiment of the invention; 
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Figure 1 1 is a flow chart illustrating a real time used vehicle purchase request submission and delivery process in 
accordance with one embodiment of the iowentian; 

figure 12 is a representation of one embodiment of a dealer record showing the crtnteits of the record fields; 
Figure 13 is a representation of one embodiment of a deaier record showing certain of trie fields implemented as 

pointers; 

Figure 14 is a representation uf one embodiment of a web page containing a hypertext link; 

Figure 15 is a representation of another embodiment of a web page containing a hypertext link; 

figure 16 is a representation of one embodiment of a web page suitable for use in the new vehicle purchase 
request creation and submission process; 

figure 17 is a representation af one embodiment of an HTML page illustrating a scrollable iist of purchase 
requests implemented as links: 

figure 18 is a high level block diagram illustrating one embodiment of the selected components contained in the 
dealer access module; 

Figure 1 9 is a representation of one embodiment of an HTML page of the home module; 

Figure 20 is a representation of one embodiment of a first HTML page of the manage customers module; 

Figure 21 is a flow chart illustrating a real time setting of a purchase request status in accordance with one 
embodiment of the present invention; 

Figure 22 is a representation of one embodiment of an HTML page illustrating a purchase request listing; 

Figure 23 is a representation of one embodiment of an HTML page illustrating a dead deal reason pull-do\nm 

menu; 

Figure 24 is a representation of one embodiment of an HTML page illustrating an updated scrollable detail display 
and an updated purchase repeat iist; 

Figure 25 is a representation of one embodiment of a buyer wes page used to specify s purchase request priority; 

Figure 28 is a representation of another embodiment of an HIM, page illustrating 3 purchase request listing; 

Figure 27 is a flow chart illustrating a reai time associating of a purchase request task in accordance with one 
embodiment of the present invention 

Figure 28 is a representation of one embodiment of a user record of the invsntion; and 

Figure 29 is a representation of one embodiment of an HTML page illustrating the appointments and tasks 
assigned to a user. 

Detailed Description 

in one embodiment of the invention, a computerised purchase request management system is provided which 
facilitates real time, efficient management of purchase requests by a seller. The system includes a plurality of HTML 
pages accessible over a network. A potentisi buyer accesses a first HTML web page over a network such as the World 
Wide Web (www) using a standard web browser. A participating selier accesses a secund HTML page over a network 
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advantageously utilizing a standard web browser and by providing a URL to identify the system. The system further 
comprises a web server and other program modules wh;eb enable to both the buyer and the seller direct and immediate 
access into 3 system database. As used aareirt. "immediately" is understood to mean occurring without loss or interval of 
time other than the nominal delay necessarily caused iiy computing components such as microprocessors, memory devices, 
software and firmware program execution times, and the like. 

A participating seller is a seller of goods which has entered into an agreement to participate in the computerized 
purchase request management system of the invention. The seller is identified by a unique seller record stored in the 
system database. The seller is further assigned an exclusive database region in the system database. Thfs seller directly 
accesses its exclusive database region over the network utilizing the system's HTML pages. 

The potential buyer uses the system's HTML web pages to formulate and submit 3 purchase request Into the 
system. The just created puichase request is communicated to an appropriate participating seller upon the system storing 
a purchase request record into the seller's exclusive database region. Details on formulating and submitting a purchase 
request, identifying a se!ler r and communicating the purchase request to the seller are included in the commonly owned U.S. 
patent application entitled REAL TIME COMMUNICATION OF PURCHASE REQUESTS filed on even date herewith having 
Attorney Docket Mo. AUTOB.040A and which is hereby incorporated by reference herein in its entirety. 

The participating seller is initially assigned a group account in the Data Center system. The seller is given a 
unique login identification and a password to access the group account. A person associated with the seller logs onto the 
system utilizing one of the plurality or HTML pages comprising the system and providing the login Identification and 
password. Initially, there are no users set up in the group acGaant. Thus, the person may advantageously establish one or 
a plurality of users for the group account. Each user created within the seller group is associated with a user profile which 
filters the information contained in the exclusive database region to be efficiently displayed to the user. 

All users in a seller group use the same login identification and password to initially log on in the Da!a Center 
system. Having logged on, a user identifies himself or herself to the system by selecting his or her use? identification frem 
a displayed list. Oetails on logging into the system, establishing user profiles, and selecting a user are included in the 
commonly owned U.S. patent application entitled A SYSTEM AND METHOD FOR SELECTIVELY RETRIEVING 
INFORMATION ITEMS filed on even date herewith having Attorney Docket No. AUT0B.G5GA and which is hereby 
incorporated by reference herein in its entirety. 

Having successfully logged onto the system, the user is able to access the information stored in its exclusive 
database region. The plurality of HTML pages comprising the system provide direct and immediate access into the 
exclusive database region. The direct and immediate access enables the user to be immediately notified of newly created 
purchase requests along with any other seller information stored in its exclusive database region, The immediate 
notification and direct database access enables the user to efficiently manage its purchase requests. 

A user =s able to immediately determine a purchase request priority upon viewing the purchase request record. 
The priority is specified by the buyer and stored as part of the purchase request record. The purchase request priority 
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enables the user to efficiently act upon the purchase request in a timely manner, for example, the user may 
advantageously consider Me purchase request priority in assigning tasks associated with the purchase request. Also, the 
user may efficiently allocate resources based upon the purchssa rerjuest prisrity bv allocating more resources tc higher 
priority purchase requests. 

For any purchase request, the user may assign specific tasks such as, by way of example, making the initial 
buyer contact, and calling the potential buyer to provide a haggle-free price quote, to any of the users in the seller groop. 
These tasks may be stored as part of the purchase request record. A summary of each assigned task is displayed along 
with the purchase request. Furthermore, an HTML page may advantageously inform a user of its assigned tasks. Thus, 
the invention advantageously provides for the assignment of separate tasks to individuals most capable of efficientiy acting 
on the purchase request. 

The invention initially assigns a status of "new" to each submitted purchase request. Users may change the 
status by assigning a status such as, by way of example, "coiri not contact", and "quoted", to the purchase request. For 
example, the user could change the status based upon factors such as the buyer informing the user of his or her intent not 
to make a purchase, the user having made a price quote, and the like. The purchase request status may be stored as part 
of the purchase request record and displayed aleng with the purchase request. Thus, thfl user may efficientiy manage its 
purchase requests by appropriately determining what action to take based on the purchase request status. 

Even though the invention is suitable for managing a purchase request for any product, the invention will be 
further disclosed in the context of managing a purchase request far a vehicle in a vehicle sates environment. Throughout 
the drawings, components which correspond to components shown in previous figures are indicated using the same 
ref erence numbers. 

In one embodiment of the invention, a Data Center system utilizes a database to store deafer information, buyer 
information, and program logic, for Bxampie, to associate the potential buyer to a specific dealer. Additionally, tfie Data 
Center system may advantageously include program logic facilitating access between the Data Center system and sources 
external to the Data Center system over a computer network. 

Computer networks suitable for use with the present invention include iecel area networks (LAN), wide area 
networks -WAN), Internet, or ether connection services and network variations such as the world wide web, the public 
internet, a private internet, a private computer network, a secure internet, a private network, 3 public network, a value- 
added network, and the like. The computers connected to the network may be any microprocessor controlled device that 
permits access to the network, including terminal devices, such as personal computers, workstations, servers, mini 
computers, main-frame computers, laptop computers, mobile computers, paim top computers, hand held computers, set top 
box for a TV, or a combination thereof. The computers may further possess input devices such ss a keyboard or a mouse, 
arid output devices such as a computer screen or a speaker. The computer network may include one or more LANs, WANs, 
internets, and computers. The computers may serve as servers, clients, or a combination thereof. 
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One network architecture which may be used with one embodiment of the invention is indicated generally hy a 
system 10 in Figure 1. The system 10 may include a network 102, which represents 3 computer network as previously 
described, providing access to and from the Data Center system. 

hi one embodiment of the invention, the Data Canter programs and Data Center dafahases comprising the Data 
Canter system preferably reside on one or more Data Center servers 1 04 and one or mere Data Center storage mediums 
106. The Data Center servers 104 and Data Center storage mediums J 06 may be interconnected by 3 LAN 108 and a 
gateway 110 to the network 102. The gateway 1 10 facilitates access to the Data Center system from the network 1G2. 

One example of the LAN 108 may be a corporate computing network, including possible access to the Internet, 
to which computers and competing devices comprising the 03ta Center system are connected. In one embodiment, the 
UN 108 conforms to the Transmission Control Protoceljimemet Protocol (TCP/iP) industry standard. In alternative 
embodiments, the LAN 108 may conform to other network standards, including, bnt not limited to, the International 
Standards Organization's Open Systems Interconnection, IBM's SNA , Novell's Netware , and Banyan VINES . 

Those of ordinary skill in the art will recognize that the Data Center programs, the Data Center databases, and 
gateway functionality may advantageously be implemented on one or more computers. These computers may be 
uniprocessor or multiprocessor machines. Additionally, these computers include an addressable storage medium such as 
random access memory and may further include a non-volatile storage medium such as a magnetic or an optica! disk. 

In accordance with one embodiment of the invention, the Data Center server 104 is connected to the Internet 
and utilizes at least 3 first user web page remotaiy accessible by a potential ftnyer. This user web page permits -he 
potential buyer to enter the necessary buyer and product information into the Data Center system. In another embodiment, 
the Data Center server 104 utilizes a second HTML page accessible by an authorized dealer. The authorized deaier utilizes 
this W3b page to access the Data Center system and features as further detailed herein. Those of ordinary skill in the art 
will recognize that 3 single web paye may be used to provide both remote buyer and dealer access to the Oats Canter 
system. Further, access for a remote buyer could be through an entirely different network than that used for access by the 
dealer. 

in one embodiment, the Data Center storage medium 106 may be configured as a database from wnich 
information can be both stored, updated, antl retrieved. For example, the database may conform to the SOL standard, in 
an alternative embodiment, the database may conform to any database standard, or may even conform 10 a non-standard, 
private specification. The Oata Center programs may provide access to the information stored on the Data Center storage 
medium 106. The Data Center storage medium 106 may be accessed by devices such as clients, servers, workstations, 
personal computers, and the like, connected to the network 102 cr the LAN 108. 

In one embodiment, the Oata Center storage medium 106 comprises exclusive database regions. The Oata 
Center assigns each participating dealsr an exclusive database region. In another embodiment, the exclusive database 
regions may be created by segmenting the storage media into distinct areas, with each area assigned to a dealer. These 
areas or regions could be dynamically allocated by the computer depending on the amount of data to be stored as the data 

_7. 



WO 00/42558 



PCT/l!S0fl/009<)2 



is entered, til another embodiment, the collection of information associated with a dealer advantageously comprises lite 
exclusive database region for the deaier. The exclusive database region may only be accessed by the assigned deafer and 
the Data Center system programs. 

in another embodiment, the Dais Cenler programs may transfer the information stored on the Data Center 
storage medium 106 to sources external to the Data Center system. For example,, vehicle inventory information may 
advantageously be transferred to other third-party computers connected to the network 102. A potential buyer can then 
access the third-party computer to view vehicle data. In yet another embodiment, the potential buyer may also submit a 
vehicle purchase request from the third-party computer. 

Various other devices m3y be connected to the LAN 1 08. for example, a workstation 1 1 2 and s personal 
computer 114 may be connected to the LAN 108 to provide access to the Data Center programs and Data Center 
databases. In one embodiment, a printer 117 may also be connected So the I AN 108 providing local and remote printing 
capabilities. 

The network 102 may connect devices, such as a user computer 118 or a user laptop 118, for example, by use 
of a modem or by use of a network interface card. As illustrated, potential buyers, may utilize such devices to remotely 
access the Data Center system via the network 102, The device used to provide access to the Data Center server may be 
referred to herein as a buyer terminal. This term is intended to include any device useful for providing access to the Data 
Center. The Data Center stores the purchase request directly into a dealer's database region. 

A plurality of dealer computers 120 may aSso be connected to the network 102 through a modem or other 
network connection device. A vehicle dealer may advantageously use the dealer computer 120 to remotely access the 
Data Center system. The device used to provide access to the Data Center server may be referred to herem as a dealer 
terminal. This tern? is intended to include any devise useful for providing access to the Data Center. The deaier obtains 
entry into the Data Center by lagging in through the second HTML page of the Data Center server 104. Upm iogginy in, 
the r;eaier attains direct access 1c its exclusive database region and the contents thereof. Moreover, because a purchase 
request is directly stared in a dealer's database region, the dealer is immediately made aware of any newly created 
purchase request. 

Although particular computer systems and network components are shown, those of ordinary skill in the art will 
appreciate that the present invention also works with a variety of other networks and components. 

!n ono embodiment, for new vehicle sales, each zip code is art exclusive territory for a (pert m3ke of vehicle. 
Thus, a particular dealer is advantageously assigned an exclusive sates reijiun based upon a vehicle make and a rip code. If 
a new vehicle purchase request is submitted, for example, for a vehicle make A in zip code 99S99, then the deaier assigned 
to zip code 99909 for the vehicle make A will ba notified of the new vehicle purchase request. In one embodiment, a 
particular dealer may be assigned multiple vehicle makes as well as multiple zip codes. In another embodiment, sales 
regions need not be based upon zip codes. Other factors such as, by way of example, telephone area codes, cities, and 
counties, may advantageous^ p'ovide the basis for determining sales regions. 
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In an alternative embodiment, one or a plurality of dealers may fas assigned to 3 single sales region. Hare, if a 
new vehicle purchase request is submitted, for example, fw a vehicle make B in a zip code 8S885, then the plurality of 
dealers assigned to rip cede 38888 for vehicle make 8 will aff be notified of the new vehicle purchase request. 

For used vehicles, the territories arc 3dvant3geousSy not exclusive. The dealer and buyer may separately specify 
a search radius. For example, each dealer may specify a search radius indicating that the dealer's used vehicles are to he 
offerer! for sale tn potential buyer's within the specified geographic radius from the dealer location. This could be done, far 
example, by utilizing zip codes to represent the area from which the dealer would accept buyers. Similarly, the buyer may 
specify s search radius indicating the desire to purchase a used vehicle from a dealer within the specified geographic radius 
from the buyer location. Thus, both the buyer's and the dealer's search radius must overlep before a potential vehicle 
match is considered. 

The dealer and the buyer may simply specify large geographic regions, such as states, counties, or zip cedes, and 
only those defers and buyers within the geographic region specifies by both are considered to determine a potential vehicle 
match. Thus, if a dealer spec-it ies New York ami New Jersey as its sales region and a buyer accesses the Data Center 
from Pennsylvania, then the dealer's used vehicles would not be considered for a potential sale. Likewise, if a buyer 
specifies 3n intent to purchase from New York, a Texas dealer will not be considered. 

Figure 2 illustrates an example ef 3 record of exclusive (fester regions suitable for use with one embodiment ol 
the invention. Advantageously, the record nf exclusive dealer regions may be implemented as a matrix. The matrix may be 
stored in the Data Center Storage medium 106. Along the horizontal axis may be listed all the regions according to zip 
codes. Along the vertical axis may be listed all the available vehicle makes. Each matrix cell 202 may contain a dealer 
identification number uniquely identifying a dealer. In this manner, each region, and each vehicie make lor (hat region, may 
be assignee to a unique dealer. In an alternative embodiment, each matrix cell 2D2 may contain one or a plurality of dealer 
identification numbers. 

Figure 3 illustrates an example of a dealer record according to one embodiment of the invention. Each dealer 
eligible to seil through the Dal a Center system is assigned a rieaier record. The dealer record may be stored in the dealer's 
exclusive database region in the Data Center storage medium 108. By way of example, six fields are illustrated comprising 
the dealer identification number 302, dealer information 304, access fist 306, product list 308, new vehicle purchase 
requests 310, and used vehicle purchase requests 312. One of ordinary skill in the art wili realize that any number of the 
fields may be broken down into additional sub-fields and that additional fields could he added. 

in one embodiment, the dealer information 302 may be comprised ef additional fields such as, for example, a 
dealer name, dealer address, dealer group, and the like. Figure 12 generally illustrates an example of a dealer record 
showing the contents ef the record fields suitable for use with one embodiment nf the invention. Furthermore, any of the 
dealer record fields may be implemented as pointers to other fields or other data records. For example, the product list may 
point to a list of new vehicle model records indicating the now vehicle models offered for sale by the dealer. Figure 1 3 
generally illustrates an example of a dealer record depicting certain cf the fielos implemented as painters. 
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In one embodiment, each new vehicle model record may in turn point tc a list of aftermarket product records. 
The aftermarket product records identify additional products offered for sale, by the dealer, tor the specific now vehicle 
model. The aftermarket product record may be comprised of the name of 3D aftermarks: product, a retail price for the 
product, a discounted price for the product, and possibly a photo showing the product. 

Iri yet another embodiment, each new vehicle model record may further point to a vehicle model specifics record 
and a vehicle mode! accessories record. The vehicle model specifics record may identify the vehicle model specifics such -as 
available transmission type, available number of doors, and the like. Tlie vehicle model accessories record may identify the 
accessories such as leather seats, power windows, end the like, available for the vehicle modes. In an alternative 
embodiment, the vehicle model specifics record contents and the vehicle model accessories record contents may be 
appropriately displayed in 3 wob page. The buyer may then specify the desired vehicle specifics and the desired vehicle 
accessories, 

in one embodiment., a new vehicle database may be comprised of a list of new vehicle records which may be 
stored in the Data Center storage medium 106. Each new vehicle model available for purchase through the Data Center 
system is associated with a new vehicle record. Figure 4 illustrates 3 new vehicle record suitable for use with the 
invention. Seven fields are illustrated comprising a vehicle make 402. vehicle model 404, vehicle year 4GS, vehicle type 
408, vehicle estimated price 410, vehicle features 412, and vehicle photo 414. it should be understood that appropriate 
fields may be added and a field may contain additional sub-fields. For example, the vehicle features field 412 may 
advantageously be comprised of a standard features field and art optional features field, in one embodiment., tiie vehicle 
type field 408 may specify whether the vehicle is a passenger car, b luxury car, a sports car, or the like. 

in another embodiment, the new vehicle record fields may be implemented as pointers Jo other fields or other 
records. For example, the vehicle photo field 414 may be implemented as a pointer pointing to a representative photo of 
the new vehicle. Thus, the representative photo may advantageously he stored in a different region in The Data Center 
storage medium 10G. In yet another embodiment, the vehicle year field 406 may be implemented as a pointer pointing to 
one or a plurality of records, each record containing, for example, a year fieic, a type field, an estimated price field, a 
features field, a photo field, and the like. 

A used vehicle record identifies a used vehicle, and is created for each used vehicle offered for sale through the 
Data Center system. The collection of used vehicle records comprise a used vehicle inventory. The used vehicle records 
may be stored in the Data Center storage medium 106. For example, the used vehicle inventory may be comprised of a 
finked fist of used vehicle records. 

Figure 5 illustrates an example of a used vehicle record suitable for use with one embodiment of the invention. 
Six fields are illustrated comprising the denier identification number 302, a dealer stock number 502, vehicle make 504, 
vehicle model 506, vehicle information 508, and vehicie photo 510. One of ordinary skill in the art will realize that 
appropriate fields may be added aod any number of the fields may be broken down into additional sub-fields. Furthermore, 
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any of the fields may he implemented as pointers to other fields or other dat3 records. For example, the vehicle photo field 
5 1 ti may advantageously point to an image of the vehicle stored else where in tha Data Center database. 

Figure 6 illustrates in more detail selected components of the Data Center server 104 of Figure 1 suitable to 
implement one embodiment of the present invention. The Data Center server 104 includes a buyer access module 602 
connected along a virtual communications path 6DB to a process purchase request module 804. Also connected to the 
virtual communications path 605 is a database access module 608 f a buyer-dealer association module 610, a dealer access 
module 812, and a network access module SI 4. 

Tiie buyer access module 602 provides a buyer an interface into the Data Center system, in one embodiment, a 
purchase request entry system comprises tie buyer access moduie 802 and may facilitate a data entry environment fer a 
buyer to enter a purchase request for 3 requested vehicle into the Data Center system. The buyer access module 602 may 
be comprised of a yeuera'e new vehicle purchase request module 6-6 and a generate used vehicle purchase request 
module 61 8. The generate new vehicle purchase request module 658 and the generate used vehicle purchase request 
module 618 may advantageously be implemented as a plurality of web pages. 

In one embodiment, the web pages may advantageously be implemented in hypertext or hypermedia. Thus, the 
web pages may contain one or a plurality of selectable items or links. The links may provide access to other web pages 
contained in the Data Center system. The plurality of linked web pages guides the user in entering the necessary data to 
creete and submit either a new vehicle purchase request or a used vehicle purchase request, in one example, Figure 14 
generally illustrates sr. example of 3 used vehicle search request fur an Aciira 3.5RL Clicking on a hypertext link 1402 
using a pointing device such as a mouse, or the like, may advantageously display another web page as generally illustrated 
by Figure 1 5. Generally depicted at 1 5Cf2 is the contents of the web p3ge pointed to by the hypertext link 1402. 

In another embodiment,, the links may provide access to any location in the World Wide Web. For example, a link 
may exist to third-party web sites which advantageously provide additional product information. 

The generate new vehicle purchase request module 616 facilitates a new vehicle purchase request creation and 
submission process, A potential buyer remotely utilizes over a network, such as the World Wide Web, at least a first web 
page in the generate new vehicle purchase request module 616 end provides information from which the process purchase 
request module 604 creates a new vehicle purchase request, likewise, the generate used vehicle purchase request module 
618 facilitates a used vehicle purchase request creation and submission process through its web pages. There may be a 
one-to-one correlation between a purchase request and a purchase request record. 

In one embodiment, a processing system comprises the process purchase request module 604 and may facilitate 
the creation of a puicftase request record. The process purchase request module 604 may create either a new vehicle 
purchase request record or a used vehicle purchase request record. The new vehicle purchase request record may be 
created from the information supplied through the plurality of web pages utilized during the new vehicle purchase request 
creation and submission process, in one embodiment, the buyer information gathered through the plurality of web pages 
comprising the generate new purchase request moduie 616 is input te the process purchase request module 604. The 
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process purchase request module 604 creates a new vehicle purchase reouest record from this information. The used 
vehicle purchase request record may likewise be created from the information supplied through the plurality of web pages 
lifted tifftini] the used vehicle purchase renuest nreatirtn and submission process. in another embodiment. We purchase 
request information may also fee obtained from web pages extemat to the Data Center system. 

As one example, f sgure 1 8 generally illustrates one web page which may be used in the new vehicle purchase 
request creation and submission process. The buyer information specified in the desired vehicle mode! 1602 may 
advantageously be input to an appropriate vehicle model field 710 in an new vehicle purchase request record illustrated in 
Figure 7. The new vehicle purchase request record will he further discussed below. 

Figure 7 illustrates a set of information fields comprising a new vehicle purchase request record according to one 
embodiment of the invention. Fifteen fields are Illustrated comprising new vehicle purchase request identification number 
702, submit time stamp 704, dealer identification number 7GB, vehicle make 708, vehicle model 710, vehicle model year 
712, purchase time frame 714, vehicle specifics 716, requested accessories 718, requested aftermarket products 720, 
buyer information 722, privacy 724, payment information 726, priority 728.. and status 730. It should be understood that 
some of these fields include several sub-fields. Thus, fcr example, the buyer information field may include sub-fields for 
name, 3ddress, zip code, e-mail address, phone numbers, 3nd contact preference. The new vehicle purchase request record 
may advantageously be stored in the Data Center storage medium 106. 

In one embodiment, the information fields may he implemented as pointers to ether fields ur other records 
containing the information. For example, the buyer information may be Implemented as a pointer. The pointer may point to 
a record comprised of, for example, the name, address, zip code, e-mail address, phone numbers, and contact preference. 
Those of ordinary skill in the art will realize that any combination of the information fields may be implemented as pointers. 

In another embodiment, certain information fields may be implemented as encoded fields. For example, the 
requested accessories field may be implemented ss a binary encoded field. Each bit position may coincide with a vehicle 
accessory such as an AMffM radio, power windows, tilt wheel, overhead console, and the fike. For example, s "V in the 
first bit position may indicate the selection of art AM/FM Radio accessory. 

Figure 8 illustrates a used vehicle purchase request record suitable for use wifh one embodiment of the invention. 
Thirteen fields are illustrated comprising used vehicle purchase request Identification number 802, submit time stamp 804, 
dealer identification number 806, dealer stock number 808, vehicle make 810, vehicle model 812, vehicle model year 814, 
purchase time frame 818, buyer information 818, payment information 820. priority 822, privacy 824, and status 828. 
One of ordinary skill in the art will realise that any number of the fields may be broken down into addiiionai sub-fields. 
Furthermore, similar to the new vehicle purchase request record, any of the fields may fce implemented es pointers, encoded 
fields, and the like. The used vehicle purchase request record may advantageously be stored in the Data Center storage 
medium 108. 

In one embodiment, the process purchase request mcdtils 604 (Figure 6) may associate the information entered 
by the buyer through either the generate new vehicle purchase request module 616 or the generate used vehicle purchase 
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request module 618 with their appropriate fields in the respective purchase request record. The process purchase revest 
module 604 may utilize the database access modulo 608 in storing the purchase request record in the Data Center storage 
medium 106 (Figure 1). The eatabase access module 603 will be further discussed below. 

In one embodiment, the purchase request record m3y be completed before being stored in the Data Center 
storage medium 106. In another embodiment, the purchase request record fields may be stared in the Data Center storage 
medium 1 08 as the appropriate information is provided by the buyer. 

in another embodiment of the invention, certain fields comprising the purchase request record may he determiner! 
by modules other than the process purchase request module 804 (Figure 8). For example, the process purchase request 
module 604 m3y request the buyar-deaier association module 810 to identify an appropriate dealer to receive the purchase 
request. Accordingly, the process purchase request module 604 may advantageously pass certain purchase request 
information to the buyer-dealer 3sseci3tiort module 610 via the virtual communications path S06. 

In one example, for a new vchisie purchase request, the buyer-dealer association module 610 may utilize the 
exclusive dealer regions record to determine a dealer identification number for the purchase request record, in one 
embodiment, as previously stated, the vehicle make a;icl the buyer zip code may be used to determine the appropriate dealer 
to receive the new vehicle purchase request. The virtual communications path 606 and the buyer-dealer association 
module 61 Q will be further discussed below. In another embodiment, the dealer identification number may he passed to the 
process purchase request module 604 for inclusion into the dealer identification number field in the new vehicle purchase 
request record. 

(n an alternative embodiment, the exclusive de3ier regions record may identify one or a plurality of dealer 
identification numbers. The buyer-dealer association module 610 may then create the necessary number of purchase 
request records, one for each of the plurality of dealer identification numbers. The dealer identification numbers may be 
passed to the process purchase request module 610, which may then create the necessary number of purchase request 
records. Thus, one or a plurality of dealers may be identified to receive a purchase request. 

in one embodiment, the bityer-desier association module 610 may advantageously determine a dealer of a used 
vehicle. For example, given the vehicle make, She vehicle model, and the vehide information, the buyer-dealer association 
module 610 may search the used vehicle inventory to locate a vehicle matching the buyer's requirements. The used vehicle 
records irt the used vehicle inventory may be searched to determine, for example, the dealer identification number and the 
dealer stock number for inclusion into the used vehicle purchase request record. 

In another embodiment, the used vehicle record may also include a unique identification number. The 
identification number may he created by the Data Center system to identify each vehicle in the Data Center system. This 
identification number may advantageously be independent of the dealer stock number. This is because the stock number 
used by one dealer for one vehicle may be identical or very similar to a stock number selected by another dealer lor another 
vehicie. in one embodiment a record may associate the unique identification number to a dealer offering the vehicle for 
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sals. The buyer-dealer association module 610 may determine the necessary information to identify the dealer, as well as 
the vehicle, from the identification number. 

in yet another embodiment, the dealer identification number and the dealer stock number may be included into 
the used vehicle purchase request record by the process purchase request module 804, For example, the dealer 
identification number and the deaier stock number may be accessed by the process purchase request module 604 at the 
time the buyer requests the vehicle, or soon thereafter. The process purchase request module S04 may at that time, or 
soon thereafter, search the used vehicle records stored in the Data Center storage medium 106 to obtain the necessary 
vehicle information. 

in an alternative embodiment, the buyer may specify one or a plurality of dealers to receive the purchase request. 
For example, the buyer may simply specify one or a plurality of dealers to receive the purchase request, lit another 
embodiment, the buyer may specify a geographic region and a vehicle description. The Data Center system may then 
identify the dealers offering for sale vehicles potentially matching the specified vehicle description in the specified 
geographic region. Then, every identified dealer may receive the purchase request. 

According to arte embodiment of the present invention, the process purchase request module 604 may further 
associate the purchase request record with the appropriate dealer record. For example, a new vehicle purchase request 
record may, upon creation, or soon thereafter, be logically connected to the dealer record new vehicle purchase requests 
field 310. The logical connection may be in the form of, for example, a direct entry of the new vehicle purchase request 
record into the new vehicle purchase requests field, or an entry into a list of new vehicle purchase request records pointed 
to by the new vehicle purchase requests field. The same association may be made between a used vehicle purchase 
request record and the dealer record used vehicle purchase requests field 312. 

Figure 9 is a block diagram illustrating one embedment of a communication between a buyer 902, a deafer 904, 
and components of the Data Center system. More particularly, a Gommtr-ication between the buyer 902, the dealer 304, a 
Data Center server 104, and a Data Center storage medium 106 is illustrated. The buyer 9D2 may access the Data Center 
server 104, through the network 102 and the gateway 110, to create and submit a purchase request in the Data Center 
system. The Data Center server 104 creates and stores the purchase request, as a purchase request record, in the Data 
Center storage medium 1 06. The purchase request is stored such that the dealer 904 may identify the purchase request at 
the time the purchase request record is created, or soon after. 

In one embodiment, the buyer S02 utilizes the components of the Data Center server 104 to create and store a 
purchase request record in the dealer's exclusive database region in the Data Center storage medium 106. The purchase 
request record is stored immediately upon the completion of the purchase request creation and submission process. The 
dealer 804 may access its database region to obtain a Istirsg of its purchase requests. Figure 17 generally illustrates a 
HTML page suitable for use in an embodiment of the invention. A scrollable list of purchase requests, advantageously 
implemented as links, is displayed generally at 1702. immediately upon the creation of the purchase request record in the 
desler 904 exclusive database region, the list of purchase requests is updated to show the just created purchase request. 
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The dealer 904 nay access the Data Center system through -he network 102 and the gateway 11 C. The dealer 
904 remote!/ accesses the Dat3 Center system over the network 102 fay providing 8 URL to identify the Data Center 
system. Dealers advantageously access the Dat3 Center by providing a URL and preferably not over the world wide web. 
Thus, access to the Data Center system may advantageously be restricted to those who know the URL and is not as 
readily reachable by web search engines. Thus, the Ufit for the buyer to access the system is advantageously 
HTTP:/(www.autobytel.com and the URL for the Dealer site, called Dealer RealTime {or DRTJ.. may advantageously be 
HTTP:/fdit.autobyte!.com, 

The dealer 904 may access its dealer record and, more particularly, its purchase request records, through the 
Data Center Server 104. In one embodiment, the appropriate dealer record field contains information from which the 
purchase request records may be identified and accessed. Alternatively, the purchase request records may comain 
information identifying the dealer 304. Thus, the purchase request ;s delivered and commtinic3ted to the dealer in real 
time, upon the creation of the purchase request record, or seon after. 

}n one embodiment, a dealer m3y be notified of a newly created purchase request record upon accessing the Data 
Center system. In another embodiment, the dealer may be notified of a purchase request created while the dealer is 
concurrently accessing the Data Center system. For example, the dealer may be viewing a screen displaying a Sst of 
purchase requests as illustrated in Figure 1 7. The appropriate field in the dealer record may be updated to identify the 
newly created purchase request while the dealer is accessing the Data Center system through a computer 1 2D. Then, the 
screen may advantageously be refreshed to dismay a list containing the newly created purchase request immediately upon 
the creation of the purchase request record, thereby communicating to the deafer the purchase request In yet another 
embodiment, the dealer may immediately be notified of a new purchase request via communication mechanisms such as e- 
maii, page, telephone message, or the like, which are triggered in response to the receipt of Ihe purchase request in the 
deafer record. 

Conventional purchase request delivery systems utilize some decree of batch processing before a purchase 
request notification is generated. In conventional systems, the delivery is generally by fax, phone ca!!, or e-mail, and the 
notification occurs at a time significantly after the submission of the purchase request, in contrast, this invention 
advantageously provides for a real rime delivery of a purchase request to the appropriate deafer. The purchase request 
delivery and notification occur when the purchase request record is created, or soon after. Moreover, unlike conventional 
notification systems, the buyer need not specify a recipient dealer. This contemplates, however, that the system m3y 
permit the buyer to select a recipient dealer or dealers. 

The virtual communications path 606 (Figure 6> facilitates communication amongst the modules comprising the 
Data Center server 104 (Figure 1). The virtual communications path 606 may be implemented as a procedure or a function 
call interface. In an alternative embodiment, the virtual communications path 608 may be implemented as an interprocess 
c rrmuniration method. For example, the modules comprising the Data Center server 104 may be implemented as one or a 
plurality of software processes. The various software processes may then communicate with one another by moans of 
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intet process communication. Those of ordinary skill in the art wi realize that the modules comprising the Data Center 
server 104 may be distributed amongst 3 plurality of Data Center servers 104 utilizing well known distributed technology 

techniques, 

Tha database access module 6Q8 piovides an interface to the information stored on the Da -a Center storage 
medium 103. The database access module 608 thus enables the Data Center server 104 modules to be implemented 
independent of the Data Center storage medium 106 specifics. This enables the Data Center storage medium 188 
specification to be altered without impacting the various modules, other than the data base 3ccess module 608, comprising 
lite Data Center server 104. 

in 3ns embodiment, as previousiy mentioned, the Data Center storage medium 106 may bG configured as a SOI 
d3tab3se. The database access module 6D8 implements the specifics ef the SQL commands to interact with the Data 
Center storage medium 106. Thus, other modules comprising the Osta Center server 104 may be developed independent 
of it* SflL specifics. For example, if the Data Center storage medium 106 is re-developed as a 082 database, only the 
database access module 808 needs to be updated. The other modules comprising the Data Center server 104 need not be 
re-developed. 

Tha buyer-dealer association module 810 associates a purchase request and an appropriate dealer. In one 
embodiment, the buyer-dealer association module 610 may receive purchase request information from the process 
purchase request module 604 via the virtual communications path 606. The buyer-dealer association module 610 may 
then access the Data Center storage medium 106, utilizing tne database access module 608 and the network access 
module S14, tc determine the appropriate deaier for the purchase request. In one embodiment, as previously stated, the 
buyer-dealer association module SIC may advantageously determine an appropriate dealer to receive the purchase request 
from the vehicle make and the buyer zip code. 

Figure 10 is a flow chart generally illustrating a res! time new vehicle purchase request submission and 
communication process according to one embodiment of the present invention. In particular, at a step 1002, the new 
vehicle purchase request information is submitted by the buyer. The buyer may utilize the generate new vehicle purchase 
request module 614 to submit the information pertaining to the new vehicle purchase request. In one embodiment, the 
buyer information may he passed tu the process purchase request module 604 as the buyer information is entered through 
each web page, nr soon thereafter. In another embodiment, the buyer-dealer association module 610 determines the 
appropriate dealer from the record of exclusive dealer regions once the buyer enters a requested vehicle model and a buyer 
lip code., or soon thereafter. 

Once the buyer information is entered, the Data Center system moves to a step 1004 wherein a check is 
performed to determine if the buyer has previously submitted a new vehicle purchase request within the previous 48 hours. 
In one embodiment, a list of new vehicle purchase request records may be searched to determine if the buyer has 
previously submitted a new vehicle purchase request. In another embodiment., the list of new vehicle purchase request 
records may be sorted based on the submit time stamp. Thus, only the new vehicle purchase request records submitted 
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within 48 hours need to fee searched. In yet another embodiment., the fist of new vehicle purchase request records may 
further he sorter! according to dealer identification number, thus requiring a search of even a smaller number of new vehicle 
purchase request records. 

In one embodiment, in step 1004, a buyer address may be used as the criteria for determining if the buyer 
previously submitter; a new vehicle purchase request within the past 48 hours. !f the buyer previously submitted a new 
vehicle purchase request, then the Data Center system moves to step 1006 and rejects the present new vehicle purchase 
request. Also, the buyer may ba presented with an error massage indicating the rejection of the rtewiy submitted purchase 
request, 

If the buyer has not submitted a new vehicle purchase request within the prior 48 hours, the Data Center system 
moves to a step 1008 wherein a new vehicle purchase request record is created hy the process purchase request module 
604 and ts stored in the appropriate dealer's exclusive database region in the Data Center storage medium 106. In one 
embodiment., the process purchase request module 604 may generate a unique number to identify the new vehicle purchase 
request record. This unique number may be associated with the new vehicle purchase request identification numher field 
702 illustrated in Figure 7. The Data Center system then moves to step 1010 wherein a confirmation is scot to the buyer. 
For example, the confirmation may be a web page displaying the purchase request number. 

At a step 1012, the new vehicle purchase request record is added to the appropriate dealer record new vehicle 
purchase requests fiefd 310. In one embodiment, as generally illustrated in Figure 13, the new vehicle purchase requests 
field 31fJ may point to a list of new vehicle purchase request records. The current new vehicle purchase request record 
may be added to the existing iist of new vehicle purchase request records. The current new vehicle purchase request 
record is immediately displayed in the list of purchase requests as generally illustrated at 1702 in Figure 17. In another 
embodiment, the dealer record new vehicle purchase requests field may additionally comprise a status flag indicating the 
new arrival of a now vehicle purchase request. 

In another embodiment, the dealer record advantageously comprises one or a plurality of beeper numbers to be 
celled upon the delivery of a new vehicle purchase request. The process purchase request module 604 may result in the 
creation of en e-mail message including, for example, beeper number or numbers for the e mail paging service to call, and 
address to an e mail pager service. The e-mail message may then be submitted to the e-mail paging service. The B-maii 
paging service may then perform the paging, cr dialing, function. As is well known in the art, suitable e-mail message 
paging services are available from companies such as Pagenet, Skytel, and MCI. 

Figure H is a flow chart qeneratly illustrating a teal time used vehicle purchase request submission and delivery 
process according to one embodiment of the invention. In particular, at a step 1 1 02, the buyer may submit information 
generally describing a vehicle. To do this, the buyer uses the generate used vehicle purchase request module 616. in one 
embodiment, the buyer may specify information such as a vehicle make, a vehicle model, and tho like. 

Once the buyer submits his or her search criteria, which generally describes the vehicle, the Data Center system 
moves to step 1 103 and conducts a search, based on the submitted search criteria, of the used vehicle records comprising 
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the used vehicle inventory in the Data Center storage medium 108. In one embodiment, the generate used vehicle purchase 
fequfist module 618 may utilize the database access module 603 to perform the search. Sf the search is Etnstitcessful st 
step 1 1 04, the Bate Center system moves to a step 1 1 05 wherein the buyer is prompted to alter the search criteria. The 
Data Center system than moves to step 1 1 02 and functions as described above. 

In one embodiment, if it is determined in step 1104 thai the search was successful, the Data Center system 
moves to step 1 1 06 wherein the results of the search are displayed to the buyer. In this step, the buyer may also view a 
more detailed description of one 3t more vehicles found in the search. Having decided on an appropriate vehicle, the buyer 
may create a purchase request for that vehicle which is submitted to the Data Center system at a step 1 1 08. 

At a step 1110, the process purchase request module 304 creates a used vehicle purchase request record in the 
appropriate dealer's exclusive database region in the Data Center storage medium 106. In this step, the buyer-dealer 
association module 610 may detetmine the dealer offering the used vehicle for sale. In one embedment, the process 
purchase request module 604 may generate a unique number to identify the used vehicle purchase lequest record. This 
unique number may he associated with the used vehicle purchase request identification number field 802 iterated in 
Figure 8. 

to one embodiment, a confirmation is sent te the buyer at a step 1112. For example, the confirmation sent may 
be a web page displaying the purchase request number. At a step 101 2, the used vehicle purchase request record is stored 
and identified in a manner simitar to a new vehicle purchase request record. Thus, the purchase request is communicated 
to the dealer in real time. Consequently, the dealer may appropriately act on the purchase request upon its submission, or 
shortly after. 

Tin? network access module 614 (Figure 6) provides the modules of the Data Center Server 104 (Figure 1) a 
uniform interface to the LAM 108. In one embodiment, the network access module 614 may be implemented as an 
application program interface. The network access module 614 enables the Oata Center server 104 modules to be 
implemented independent of the underlying network specifics. Thus, the underlying network specifies insy be altered 
without impacting the various modules, other than the network access module 614. comprising the Data Center server 
104. 

The dealer access module 612 provides a dealer an interface into the Data Center system. In one embodiment, s 
dealer management system comprises the tfeaier access module 612 and may facilitate the dealer's managing its purchase 
requests. More particularly, a dealer may directly access its exclusive database region, and the information contained 
therein, by logging into the Oato Center system through the dealer access module 612. In one embodiment, the dealer 
access module 612 may be implemented as a plurality of HTML sages providing the dealer a mechanism to access its 
exclusive database region. The Data Center system may advantageously communicate to the dealer its purchase requests 
through one or a plurality of the HTML pages. An example ol one such HTML page is illustrated in Figure 17. The dealer 
may eSso advantageously perform real time operations such as, purchase request management, inventory management, and 
the like, through the plurality of HTML pages. 
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Figure 18 illustrates selected components of the dealer access module 612 suitable to implement one 
embodiment oi the invention. The dealer access module 612 may be comprised of a login module 1802. a tome module 
1804. a manage customers module 18T0 n.ii a nvt f>gp nventorv module 1808. as well as ether modules. The modules 
may be comprised of one or a plurality of linked HTML pages which enable tiic participating dealers to interact with the 
Dats Center system. The modules may further comprise one or more action response modules., such as, by way of 
example, purchase request management module, purchase request listing module, purchase request detail display module^ 
status change module, associate task module, modify last; module, and list tasks macule, which enable a user to efficiently 
manage purchase requests. 

hi one embodiment, 63ch participating dealer or dealer group is provided with a dealer group login account which 
the dealer uses to access the Data Center system. Initially, there are ordinarily no users set up in the dealer group login 
account. Associated with each dealer group login account is a unique dealer group profile record identifying certain 
characteristics of the dealer group as well as other tuneable characteristics. The dealer logs into the system using a login 
identification and a password. Upon initially logging into the Data Center system, the dealer creates one or mure useri 
with which tc access the system. A user can be, for example, a deaier, sales manager, salesperson, or anyone associated 
with a deaier or dealer group, and who may properly access the exclusive database region and the information contained 
therein, 

A user profile record substantially similar to tm> group profile record is associated with each user. The user 
profile record is initially created by the dealer at the time the dealer creates the user. The user profile record comprises one 
or more filter conditions, and the user profile record is used to filter the information contained in the dealer's exclusive 
database region. For example, 3 sales manager may have specified that only purchase requests with "sold" status is to be 
displayed. Then, for this sales manager, only purchase requests with "sold" status will be displayed. All other information 
in the exclusive database region will be filtered out. !n this and subsequent examples, the use of "user" is not intended to 
be limiting, but for clarity, examples may also be provided using titles such as, by way of exarrtpie, sales manager, 
salesperson A, and salesperson B. 

Figure 28 illustrates an example of a user record according to one embodiment of the invention. The Oata Center 
system advantageously stores a user record for each user created by each dealer or daaler group login account. The user 
record may advantageously be stored in the dealer's exclusive database region. By way of example, five fields are 
illustrated comprising a user identification 2802, user profile 2804, deals; identification number 2608, purchase request 
list 2808, and assigned tasks 2810. One of ordinary skill in the art will realize that any number of the fields may be 
implemented as pointers to other records or fields, may be broken down into additional sub-fiies, and that additional fields 
could be added. 

In one embodiment, a first HTML page comprising the login module 1802 may be accessed via the internet by a 
person associated with a deaier to access the Data Center system. As an oxampSe, a person associated with a dealer may 
advantageously provide a login identification and password pair associated with a dealer group account utilizing the first 
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HTML page. Having provided a valid login identification and password pair, a second HTML page may request the person 
to identify himself or herself by selecting a user from a list of users associated with the dealer group account and 
previously created. Upon selecting a user, a first HTML page of the home module 1304 may be displayed. In another 
embodiment, the person may utilize the lecin module 18D2 te create additional users belonging to the dealer group, delete 
existing users Irani the dealer group, and modify existing user profiles in the dealer group. 

In one embodiment, the home module 1804 may advantageously provide the user access to the features and 
components comprising the dealer access module 612. Figure 19 generally illustrates such an HTML page of the home 
module 1804. The HTML page contains a master table of contents 1904 providing a summary listing of the features and 
contents o? the dealer access module 612. The summary listing may advantageously be tiered to better illustrate the 
organization of the dealer access module 6 1 2. For example, each module comprising the dealer access module 61 2 Is listed 
in the first tier while eacn module's components is listed in the second tier. Additionally, other summary information 
pertaining te the user such as, hy way of example, a rtumher of new purchase requests, and a number of appointments 
today, may advantageously be presented. The summary information displayed may be dependent on the particular user 
profile record and may also be tiered. 

Each entry in the master I3b!e of contents 1904 is preferably implemented as a hypertext link providing direct 
access to a linked HTML page. In another embodiment, the other summary information contents may also be implemented 
as a list of links to other HTML pages containing more detailed information. For example, clicking on the new purchase 
request link 1902 with a pointing device such as a mouse, or the like, may further display an HT1V5L page listing the new 
purchase requests as generally illustrated in Figure 17. Tabs may also be implemented to provide direct 3scess to specific 
HTML pages comprising the deafer access module 612. 

The purchase request management module advantageously comprises the manage customers module 1 806 and 
may facilitate the efficient real time management of a dealer's purchase requests. A user utilizes the manage customers 
module 1806 to access the purchase requests seismitled to the dealer. Several properties may advantageously be 
associated with a purchase request such as, by way of example, a purchase request status, e purchase request priority, 
and a purchase request task. The user may advantageously perform operations such as associating a status to a purchase 
request, determining a purchase request priority, scheduling activities and assigning tasks based upon the purchase request 
priority, associating a task to a purchase rsnuest, assigning a purchase request task to a user, and the tike. 

Figure 20 generally illustrates a first HTML page of the manage customers module 1803. A table of contents 
listing the contents of the manage customer module 1806 is displayed generally at 2002. A total number of purchase 
requests satisfying the filtering conditions specified in the user profile fie'd 2804 is specified at a purchase requests total 
2004. A number of appointments for the user scheduled for the current day is specified at a today's appointments total 
2006, 

in one embodiment, the total number of purchase requests may be obtained by searching through the contents of 
both the new vehicle purchase requests field 310 and the used vehicle purchase requests field 312 of the appropriate 
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dealer record and determining the number of purchase requests satisfying the filtering conditions. The purchase requests 
satisfying the filtering conditions may advantageously be identified by the new vehicle purchase request identification 
number 702 or tfta used vehicle purer sse request identification number 802. These identification numbers may be stored 
in the purchase request iist field 28D8 in the user record for quick and efficient reference. Those of ordinary skill in ton art 
will realize that thete are other methods of identifying the purchase requests satisfying the filtering conditions such as 
maintaining another copy of the purchase request record in the database, creating a record of database Ms pointing to the- 
purehase request records satisfying the tittering conditions, and the iike. 

in one embodiment, each purchase request is identified by a status such ss new, could not contact, quoted, 
pending, sold, and dead deal. The Oata Canter system initially assigns a status of "new" to each purchase request 
submitted to the system, Tiiis status may 3rivantageous!y be stored in the status field 730 in the new vehicle purchase 
request record or the status field 826 in the used vehicle purchase request record. As is generally illustrated at 2008 in 
Figure 20,. the number of purchase requests may he listed according to the purchase request status. In an alternative 
embodiment, the iist may be comprised of links to other HTML pages which provide the use- a more detailed purchase 
request listing such as that shown in Figure 17. 

Figure 21 ;s a flow chart generally illustrating a real time setting of a purchase request status according to one 
embodiment of the invention. In particular, at a stap 2102, the user utifees a purchase request listing module to obtain a 
listing of the purchase requests satisfying the filter conditions specified m the user profile field 2804 in the user record. As 
an example, a salesperson may click on the purchase requests total iink 2004 (Figura 20) using a pointing device such as a 
mouse, or the like, to access an HTML page displaying the list of purchase requests. Such a list suitable for use with one 
embodiment of the invention is generally illustrated by a purchase request listing 2202 in Figure 22. 

The purchase request listing module may iist the purchase requests according to date, status., and customer 
name. Also, the purchase requests may advantageously be displayed with alternating backgrounds to better distinguish 
cne purchase request from the next. In another embodiment, the purchase requests may he displayed in differing colors 
based upon, for example, the status and the date. Thus, for example, new purchase requests that have not been acted on 
for 48 hours may be displayed in red to indicate that some action should he taken. The displayed information is obtained 
from the appropriate fields in the new vehicle purchase request records and the used vehicle purchase request records. 

In one embodiment, a scrollable detail display 2206 appearing en the right side of the HTML page generally 
illustrated in Figure 22 does not initially display the details of a purchase request. The fight side of the HTML page initially 
displays a message substantially similar to the message displayed in Figure 17. At a step 2184, the user utilizes a 
purchase request detail display module to display a purchase request's details, for example, the salesperson can select a 
purchase request from the purchase request listing 2202 by clicking on a customer name link 2204, "Joseph, Tester" in 
the example, using a pointing device such as a mouse, or the iike. This causes the purchase request detail display module 
to display the contents of Tester Joseph's purchase request in the scrollable detail display 2206 in a step 21 06. As can be 
seen in the figure, the location of the side bar m the scrollable detail display 2206 is shown scrolled to the bottom. The tap 
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of the scrollable detail display 2206 contains information substantially similar to that in the scrollable detail display 2206 
illustrated in Figure 26 except that in this example, Hie displayed name would be "Tesier Joseph" instead of "Joseph 
Tester" as illustrated in f ipre 26. 

in a step 2108, the user may utilize a status change module to update the purchase request status. In one 
embodiment, the status change module comprises a status change screen 22D8 within the scrollable detail display 2206 
and facilitates the purchase request status update. The user may advantageously change the status to reflect certain 
buyer feedback obtained during a communication with the buyer. The communication may, for example, be a phone 
conversation, an e-mai! message, or a face-to-face meeting. For example, the salesperson may have provided the buyer a 
quote a' S 1 0,000. The salesperson could then change the status of the purchase request from its current status to a new 
status to indicate "quoted." The new status may be selected from a status pull-down menu 2210. Selecting the "quoted" 
status from the status pull-down menu 2210 requires the user to provi-ja an amount quotBd in a quote amount tield 221 2. 
In the example, the salesperson would have entered "100GO" in the quote amount field 2212. Also, selecting a "dead deal" 
status front the status puli-dowrt menu 22 1 D requires the user to provide a reason for the dead dea! by making a selection 
from a dead deal reason pull-down menu 2302 {Figure 23). Fields requiting user input may be indicated, for example, by a 
flashing red fight appearing beside the required field. 

In one embodiment, the user m3y also specify a memo in a memo field 2214. For example, the salesperson may 
provide a memo indicating the reason for the price quote of $10,000. The contents of the memo may be maintained along 
with the purchase request status and may advantageously be displayed along with the status. The contents of the memo 
may be displayed using a different font or a different color to better identify the memo's contents In another embodiment, 
the memo contents may be maintained in a separate record pointed to hy either the status field 730 in (he new vehicle 
purchase request record or the status field 828 in the used vehicle purchase request record. 

Having made the appropriate status selection, the user clicks on a submit button 2304 using a pointing device 
such as a mouse, or the like, to activate the status change. The status change module immediately access the appropriate 
records in the dealer's exclusive database region and makes the necessary changes. Subsequently, the status change 
module immediate-y updates both the scrollable detail display 22D8 and the purchase request listing 2202. Figure 24 
generally illustrates an updated HTML page containing the updated scrollable detail display 2208 and the updated purchase 
request listing 2202. As can be seen in the figure, the location of the side bar in the scrollable detail display 220S is shown 
scrolled to the middle. In tne embodiment, a purchase request status list 2402 immediately displays the new purchase 
request status as part of a purchase request status history list. 

In another embodiment, the status change moduie immediately updates all displays containing a modified 
purchase request to redact a purchase request modification. In one example, salesperson A may update Tester Joseph's 
purchase tersest status from new to quoted. Salesperson A's scrollable detail display 2208 and purchase request listing 
2202 is immediately updated to reflect the status change to purchase request X. ff salesperson 6 is viewing a purchase 
request listing 2202 containing Tester Joseph's purchase request at substantially the same time as when salesperson A 
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performs the status change to Tester Joseph's purchase request, then salesperson B's purchase request listing 2202 is 
immediately updated to reflect the status change to Tester Joseph's purchase request. 

hi 3:1 alltrastive embodiment, not all users way be able to change a purchase request's si3tus. The user profile 
record may advantageously contain information indicating whether the user is permitted to change the purchase request's 
status. For example, a sales manager may advantageously ha permitted to perform a purchase request status change 
while salespersons may not able to perform a purchase request status change. The saies manager's profile record will 
indicate the ability of the sales manager to change a purchase request's status, in contrast, the salesperson's profile 
record will indicate the inability of the salesperson to perform this function. Thus, if a salesperson tries to change a 
purchase request's status, an error message may advantageously appear. 

In one embodiment, each purchase request has an associated purchase request priority. The buyer enters the 
purchase request priority through a web page utilized during the purchase request formulation and submission process. 
Figure 25 generally illustrates such a buyer web page suitable for use in one embodiment of the invention. The buyer 
selects a purchase time period from a purchase time period list 2502. Depending on the type of vehicle requested, either 
new or used, the buyer's selection is input into either the priority field 728 in the new vehicle purchase request record or 
the priority field 822 in the used vehicle purchase request record, 

In one embodiment, 3 purchase time period of 48 hours is associated with 3n '"A lmmediate" priority, a purchase 
time period of 2 weeks is associated with 3 "B-Sertous" priority, and a purchase time period of 30 days is associated with 
a "C-Fufure" priority. For example, a huyer, Joseph Tester, ni3y select "2 weeks" from the purchase time period list 2502. 
The purchase request created will be assigned a priority of "B-Serious" by the Data Center system. A user belonging to the 
appropriate dealer group may then log into the Data Center system and access the purchase request listing 2202 generally 
illustrated in Figure 26. The user may then use a pointing device such as a mouse, or the like, and click on the customer 
name link 2204 for Joseph Tester to display the details of Joseph Tester's purchase request in the scrollable detail display 
2206. A purchase request priority display 2602 advantageously displays Joseph Tester's purchase request priority. In 
another embodiment, the time period specified in the purchase time period list may also be displayed in the purchase 
request pnoity display 2602. In an alternative eoihodiment, the user may sort the purchase request according to its 
priority, and may selectively display purchase requests depending on its priority. 

Thus, the purchase request priority enables the user to bettor allocate resources in order to consummate a sale. 
The user may advantageously schedule daily tasks by focusing on the higher priority purchase requests. As 3n example, a 
salesperson may advantageously plan his or her daily activities by focusing mare effort and attention to purchase requests 
with a higher priority. .Moreover, the user may assign tasks to the appropriate sales staff based on the purchase request 
priority. For example, a sales manager may advantageously assign the higher priority purchase requests or the higher dollar 
value purchase requests to the tnore senior o' more capable sates staff. 

Figure 2? is a flow chart generally illustrating a real t;me associating of a purchase request task to a purchase 
request, and the assignment of the purchase request task to a user according to one embodiment of the invention. In 
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particular, at a step 27G2, the user obtains a listing of the purchase requests satisfying the user's filter conditions as 
specified in the user's profile record. For example, a sales manager, identified in the example as "1 DRT Classic Interface," 
may obiain a fist of ail new purchase requests. This is passible by specifying in the sales manager's profile record his or 
her desire to only list new purchase requests. The procedures previously discussed above in conjunction with the step 
2102 may advantageously be used to obtain the purchase request listing 2202 (Figure 22). At a step 2704, the user 
selects a purchase request from the purchase request feting 2202. The user clicks on the customer name link 2204 using 
a pointing devise such as a mouse, or the like. This immediately causes the contents of tiie selected purchase request to 
be displayed in the scrollable detail display 2206 in a step 2706. As an example, the sales manager can select the 
customer name link 2204 for Tester Joseph to display the contents of Tester Joseph's purchase request in the scrollable 
detail display 2206. 

ifi a step 2708, the user may utilize an associate task module to associate a task to the purchase request. In one 
embodiment, the associate task module comprises an assign task screen 2216 snrj facilitates the assigning of a specif ;c 
task to a user in the dealer group. In assigning tha task, the user may advantageously consider factors such as a user's 
schedule, user's capabilities, buyer's desires, purchase request status, and purchase request priority. As an example, the 
safes manager may determine that, of all the qualified salespersons, Bill Basktn is the most qualified to handle Tester 
Joseph's purchase request. The tasks may he comprised of, for example, not applicable, C3it delivery, e-mail, foiiow-up, 
otter, and test-drive. 

In one embodiment, the user may select an appropriate task from a task pull-down menu 2218 to associate to 
the purchase request. The user selects a date the task is to be carried oirt in a task date field 2220, The user selects a 
time for the task to be carried out by making a selection in a task time pull-dawn menu 2222. The time pull-down menu 
may list the times in ;b minute increments. Finally, the user may assign a user to perform the task by making a selection 
from an 3ssign to user pull-down menu 2224. The assign to user pull-down menu 2224 lists all users belonging to the 
same deafer group as the user. For example, the sales manager may assign Bill Baskin the -ask of sending Tester Joseph 
an e mail message at 10:00 A.M. on December 16, 1998. 

Havitig provided the necessary information, the user clicks on a submit button 2304 (Figure 23) using a pointing 
device such as a mouse, or the like, to activate the association and assignment of the specified task to the purchase 
request. The associate task module immediately access the appropriate records in the dealer's exclusive database region 
and makes the necessary changes. Subsequently, the associate task module may immediately update both the scrollable 
detail display 2206 and the purchase request listing 2202. The scrollable detail display 2206 comprises a purchase 
request task list 2404 which immediately displays the newly assigned task. The newly assigned task may initially be 
assigned an active status. For example, immediately upon the sales manager submitting the task, both the scrollable detail 
display 2206 and the purchase request listing 2202 will display the just created task assignment. As is illustrated in Figure 
24, the purchase request task fist 2404 displays both the assignor of the task as weif as the assignee. 
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lii one embodiment, the specified task may be includes! in the assigned tasks field 2810 in the user record of the 
user assigned the task. The user may also specify a memo in the memo field 2214. The contents of the memo may be 
maintained along with the purchase request task and ma\, ^ami^ous^ Sa displayed a;ong with the task. Fnr example, 
the sales manager may state in the memo fiaid 2214 his or her reason tor assigning Bill Baskin the task. Further, the sales 
manager may be offered the capability of blocking others from viewing tha contents of his or her memo f ieid. 

In one embodiment, the user may advantageously modify a purchase request task by utilizing a task edit link 
2406. Clicking on the task edit link 24G8 using a pointing device such as a mouse, or the like, activates a modify task 
module. The modify task module may display in the scrollable detail display 2206 a modify task screen. The user may 
advantageously use the modify task screen to m3ke appropriate changes to the purchase request task. As an example, the 
sales manager may modify the date, the time, the task, and the assigned user. Also, the sales manager may 
advantageously modify the purchase request task status to. for example, active, inactive, or canceled, 

In one embodiment, a user may advantageously view the tasks assigned to the user by clicking on the today's 
appointments total link 2D0B (Figure 20} using a pointing device such as a mouse, or the like. Subsequently, a list tasks 
module may display an HTML page which lists the user's appointments as well as the tasks assigned to the user. Figure 
29 generally illustrates such an HTML page suitable for use with one embodiment of the invention. Far example, Bill 
Baskin may access the Data Center system and click on the today's appointments total link 2006 to view a list of his 
tasks. The assignment to send Tester Joseph an e-nwf at 10:00 A.M. cn December 18, 1998, may advantageously 
appear in Bill Baskin's task list. (Figure 29 illustrates an HTML page listing the appointments and the tasks for a different 
user.) 

In another example, the sales manager may click on the customer name link 2204 for Tester Jo eph u nig a 
pointing device such as a ntsKise, or the like. This immediately causes the contents of Tester Joseph's purchase request to 
be displayed in the scrollable detail display 2206. The sales manager may also assign Bill Baskin the task of following-up 
with Tester Joseph at 10:30 A.M. on December 18, 1998. Once the sales manager submits the t3sk to the associate task 
module, the assigned tasks immediately appear in the purchase request listing 2202 3nd the scrollable detail display 2206 
(Figure 24). 

in another embodiment, all purchase request listings 2202 and scrollable detail displays 2206 containing Tester 
Joseph's purchase request is immediately updated to reflect the task assignment. For example, ii Biil Baskin happened to 
he viewing a purchase request listing 2202 at substantial:* the same time as when the sales manager assigned the task. 
Bill Baskin's purchase request listing 2202 will immediately be updated to reflect the just created task assignment. In 
another embodiment, ;f Bill B3skin is viewing the HTML page listing his appointments at substantially the same time as the 
assignment of the task,, the HTML page is immediately updated to reflect lite task assignment. 

In one embodiment, Bill Baskin may advantageously assign to himself tasks as a reminder to perform the 
assigned task. For example, Bill Baskin can assign to himself the task of calling a potential buyer on a specific day. Once 
the task is completed, Bill Baskin can edit the purchase request task status to inactive to, for example, signify the 
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completion of the task. As another example, another salesperson may advantageously assign salesperson 8i Baskin the 
task of sending an e-mail message to a prospective buyer. 

in an alternative embodiment, certain users may advantageously be qualified to assign tasks. The user profile 
resort] may advantageously contain information indicating whether the user is permitted to assign tasks. As an example, 
sales managers may be able to assign tasks to salespersons, out salespersons wauirj not be able to assign tasks to otiier 
salespersons or sales managers, In yet an alternative embodiment, the assigned task may advantageously be a directive. 
For example, if a sales manager assiyned a task to a salesperson, then the sales manager can modify (he task assignment. 
In contrast, the salesperson will not be able to modify the task assignment. 

This invention may be embodied in other specific forms without departing from the essential characteristics as 
described herein. The embodiments described above are to he considered in ail respects as illustrative only and not 
restrictive in any manner. The scope of the invention is indicated by the following claims rather (ban by ihe foregoing 
description. 
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WHAT IS CLAIMED IS ; 

1. A method of managing 3 purchase request in a Data Center system, said method comprising She acts, 

of; 

receiving in said Data Center system a purchase request from a potential buyer; 
providing at least one user access to said purchase request; and 

displaying to said user details 01 said purchase request, said user ascertaining a property of said 
purchase request based upon said purchase request detail, said user acting based upon said purchase request 
property, wherein said action taken by said user is one of a plurality of possible actions and said Data Center 
system having one or mure action response modules to assist the user in taking at least one of said actions. 

2. The method as defined in Claim 1 , wherein said property is a priority. 

3. The method as defined in Claim 2, wherein said priority is selected from the group comprising A- 
immediate, 3-Serious, or CFuture. 

4. The method as defined in Claim 1 , wherein said property is a status. 

5. The method as defined in Claim 4, wherein said status is selected from the group comprising new, 
could not contact, quoted, pen&ng, sold., or dead dea!. 

6. The method as defined in Claim 1, wherein said proper! y is a purchase request task. 

7. The method as defined ir. Ciaim 6, wherein said task is selected from the group comprising not 
applicable, coll, delivery, e mail, follow-up, other, and test-drive, 

8. The method as defined in Claim 1, wherein said user is a sales manager. 

9. The method as defined in Claim 1, wherein said user is a salesperson. 

10. The method as defined in Claim 1, wherein said acting includes s sales manager setting 3 purchase 
request status based upon a communication with said buyer. 

11. The method as defined in Ciaim 1 , wherein said acting includes a salesperson setting a purchase 
request status based upon a communication with said buyer. 

12. The method as defined in Claim 1, wherein said acting includes a sales manager associating one or 
more purchase request tasks with said purchase request, wherein said one or mors purchase request tasks is assigned to 
one or more users, 

13. The method as defined in Claim 1, wherein said acting includes a salesperson associating one or more 
purchase request tasks with said purchase request, wherein said one or more purchase request tasks is assigned to one or 
more users. 

14. The method as defined in Claim 1, wherein said acting includes scheduling daily tasks, said scheduling 
performed by utilizing said one or more action response modules. 

15. The method as defined in Claim T, wherein said acting includes a sales manager allocating resources, 
said allocating performed by utilizing said one or more action response modules, 
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1 6. The method as defined in Claim 1, wherein said acting includes a salesperson allocating resources, said 
allocating performed by utilizing said one or more action response modules. 

17. Trie method as defined in Claim 1. wherein said acting is performed in response to viewing a purchase 
request priority in a purchase request detail display. 

18. The method as defined in Claim 1, wherein said acting is performed in response to viewing 3 purchase 
request task in a purchase request detail display. 

19. The method as defined in Claim 1, wherein sard acting is performed in response to viewing a purchase 
request status in 3 purchase request o'efaii display. 

20. The method as defined in Ciaim 1 , wherein said acting is performed in response to viewing a purchase 
request task in a purchase request listing. 

21 . The method as defined in Claim 1 wherein said acting is performed in response to viewing a purchase 
request status in a purchase request listing. 

22. The method as defined in Claim 1, wherein said acting is performed in response to viewing an HTML 
page listing appointments and tasks. 

23. The metherj as defined in C!3im \, additionally comprising die act of updating a detail display, said 
updating per formed hy one or mere said action response modules, said updating performed immediately upon said user 
action, wherein said detail display includes a purchase request modification. 

24. The method as defined in Claim 1 r additionally comprising the act of updating a purchase request 
listing, said updating performed oy one or more said action response modules, said updating performed immediately upon 
said user action, wherein said listing displays s purchase request modification. 

25. The method as defined in Ciaim I, addmortaliv comprising the act of updating a display, wherein said 
display contains a modified purchase request. 

28. A purchase request management system, wherein said purchase request is remotely managed by a 
user over a computer network, said purchase request management system comprising: 

a system database which provides 3n elusive database region for each of a plurality of dealers; 

a plurality of purchase requests created by potential buyers, said purchase requests being stored in 
said central datahsse; and 

a purchase request management module which provides said user access into said exclusive database 
region, said purchase request management module includes one or more action response modules. 

27. The management system as defined in Ciaim 26, additionally comprising a dealer terminal, said dealer 
terminal displaying a split screen and the split screen lists the purchase requests on one side and a purchase request detail 
on the other side. 

28. The management system as defined in Ciaim 27, wherein said iisl of purchase requests includes an 
assigned user. 
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29. The management system as defined in Claim 27, wherein said purchase request details inciufe-a 
purchase request task list. 

32. The management system as defined in Claim 29, wherein said purchase request task list includes an 
assigned user. 

31. The management system as defined in Claim 29, wherein said purchase request task fist includes an 



32. The management system as defined in Claim 26, wherein said user is a sales manager. 

33. The management system as defined in Claim 26, wherein said user is a salesperson. 

34. A purchase request management system having a system database, said system database including an 
exclusive database region for each of a plurality ef dealers, said system database containing at least one purchase request, 
wiierein at least one user has access to said purchase request in said exclusive database region, said management system 
comprising: 

means for listing said purchase request; 

means for selecting said purchase request; 

means for displaying details of said purchase request; and 

means for acting on said purchase request, wherein said acting includes utilizing one or more action 
response modules. 

35. The management system as defined in Claim 34, wherein said means for displaying displays a purchase 
request list on one side and a purchase request detail on the other side. 

38, The management system as defined in Claim 35, wherein said purchase request list includes an 



37. The management system as defined in Claim 35, wherein said purchase request detaii includes a 
purchase request task list 

38. The management system as defined in Claim 37, wherein said purchase request task iisi includes an 
assigned user. 

39. The management system as defined m Claim 37, wherein said purchase request task list includes an 
assigning user. 

40. The management system as defined in Claim 34, wherein said user is a sales manager. 

41. The management system as defined in Claim 34, wherein said user is a salesperson. 

42. Apparatus comprising: 

a Data Center having a microprocessor and storage media in communication therewith, said storage 
media storing a buyer access module, a dealer access module and a database; 

a plurality of buyer terminals located remotely from said Data Center and remote from one another, 
said buyer terminals m communication with said Data Center; 
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3 piarafity of dealers located remote from said Data Center, each of said dealer haying a plurality of 
dealer terminals in communicaticr. with said Data Centar; 

said buyer access module including a purchase request submission serpen accessible to said buyer 
terminals, said screen including a data entry location permitting the buyer to enter information regarding the 
product the buyer would like to purchase and a purchase request submission option that enters buyer's purchase 
request into said data center's database when said option is seiected by the buyer; 

S3id dealer access module including a purchase request management screen accessible to said dealer 
which is periodically refreshed to reflect current purchase request information in the database; and 

said purchase request management screen including a fist of purchase requests along with the status 
of said requests, said purchase rsquast management screen further including a task assignment option permitting 
assignment of a purchase request to an individual salesperson when seiected by the dealer. 

43. The apparatus as defined in Claim 42, wherein said task assignment is performed by a saies manager. 

44. The apparatus as defined in Claim 42, wherein said fist of purchase requests is different for different 

dealers. 

45. The apparatus as defined in Claim 42, wherein said purchase request management screen includes a 
purchase request priority. 

46. Tha apparatus as defined in Claim 42, wherein said purchase request management screen includes s 
purchase request status. 

47. The apparatus as defined in Claim 42, wherein said purchase request management screen includes a 
status change option permitting changing of a purchase request status. 

48. The apparatus as defined in Claim 42, wherein said purchase request management screen refresh is 
performed Immediately upon a change to information displayed in said screen. 

49. The apparatus as defined is Claim 42, wherein said purchase request management screen includes a 
purchase request task list. 

50. The apparatus as defined in Claim 42, wherein said purchase request management screen includes a 
purchase request status list. 

51. The apparatus as defined in Claim 42, wherein said buyer terminals communicate with said Data 
Center through the internet. 

52. The apparatus as defined in Claim 42, wherein said buyer terminals communicate with said Data 
Center through a URL, said URL is on the world wide web, 

53. The apparatus as defined in Claim 42, wherein said dealer terminals communicate with said Data 
Center through a URL, said URL is on a private area of the Internet. 

54. The apparatus as defined in Claim 42, wherein said buyer terminals are stand atone personal computers 
connected to the internet 
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55. The apparatus as defined in Claim 42, wherein said purchase request management screen displays a 
purchase request list en orb side and a purchase request detail on the other side, 

56. Apparatus comprising: 

a Data Center having a microprocessor and storage media in comrnunicaiion therewith, said storage 
media storing a dealer access module, and a database, wherein said database storing one or more purchase 
requests; 

a plurality of dealers located remote from said Data Center, each of said dealer having a plurality sf 
dealer terminals in communication with said Data Center; 

said dealer access nodule including a purchase request maitdgernerrt screen accessible to said dealer 
which is periodically refreshed to reflect current purchase request information in the database; and 

said purchase request management screen including a list of purchase requests along with the status 
of said requests, said purchase request management screen further including a task assignment option permitting 
assignment of a purchase request to an individual salesperson when selected by the deafer. 

57. A method of managing a purchase request in a Data Center, wherein said Data Center includes a 
microprocessor and a storage media in communication therewith, said storage media storing a buyer access module, a 
dealer access module and a database, said method comprising the acts of: 

providing a plurality of buyer terminals located remotely from said Data Center and remote from one 
another, said buyer terminals being m communication with said Data Center; 

providing a plurality of dealers located remote from said Data Center, each of said dealer having a 
plurality of deafer terminals being in communication with said Data Center; 

receiving from a buyer a purchase request submitted through said buyer access module induing a 
purchase request submission screen accessible to said buyer terminals, said screen including a data entry 
location permitting the bayer to enter information regarding the product the buyer would like to purchase and a 
purchase request submission option that enters buyer's purchase request into said Data Center's database when 
said option is selected by the buyer; and 

providing said dealer a purchase request management screen accessible to said dealer which is 
periodically refreshed to reflect current purchase request information in the database, wherein said dealer access 
module includes said purchase request management screen, said purchase request management screen including 
a list of purchase requests along with a status of said purchase requests, said purchase request management 
screen further including a task assignment option permitting assignment of a purchase request to an individual 
salesperson when selected by the dealer. 

58. The method as defined in Claim 57, wherein said task assignment is performed by a saies manager. 

59. The method as defined in Claim 57, wherein said list of purchase requests is different for different 

dealers. 
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80. The method as defined in Claim 57, wherein said purchase request management screen includes a 
purchase request priority. 

61. The method as defined in Claim 57, wherein said purchase request management screen includes a 
purchase request status. 

62. The method as defined in Claim 57, wherein said purchase request management screen inciudes a 
status change option permitting changing of a purchase request status. 

63. The method as defined in Claim 57, wherein said purchase request management screen refresh is 
performed immediately upon 3 change to information displayed in said screen. 

54. The method as defined in Claim 57, wherein said purchase request management screen includes a 
purchase request task iist. 

65. The method as defined in Claim 57, wherein said purchase request management screen includes a 
purchase request status list 

68. The method as defined in Claim 57, wherein said buyer terminals communicate with said Data Center 
through the Internet 

67. The method as defined in Claim 57, wherein said buyer terminals communicate with said Data Center 
through a URL, said URL is on the world wide web. 

88. The method as defined in Claim 57, wherein said dealer terminals communicate with said Data Center 
through a URL, said URL is on a private area of the Internet. 

88, The method as defined in Claim 57, wherein said buyer terminals are stand alone persons! computers 
connected to the Internet 

70. The method as defined in Claim 57, wherein said purchase request management screen displays a 
purchase request list on one side and a purchase request detail on the other side. 

71. The apparatus as defined in Claim 42, wherein said management screen includes a status change 
option permitting changing of a purchase request status fry the dealer. 

72. The apparatus as defined in Claim 71 , wherein said changing of a purchase request status is by a sales 

manager. 

73. The method as defined in Claim 57, wherein said management screen includes a status change option 
permitting changing of a purchase request status hy the daaler. 

74. The method as defined in Claim 73, wherein said changing of a purchase request status is by a sales 

manager. 

75. A method of managing a purchase request in a Data Center, wherein said Data Center includes a 
microprocessor and a storage media in communication therewith, said storage media storing a dealer access module and a 
database, said database storing one or more purchase requests, said method comprising the acts of: 
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providing a plurality of dealers located remote from said Data Center, each of saitf deafer having a 
piuraiity of deaier terminals being in communication with said Data Center; ami 

providing said dealer a purchase request management screen accessible to said dealer which is 
periodically refreshed to reflect currant purchase request information to the database, wherein said dealer access 
module includes said purchase request management screen, said purchase request management screen including 
a list of purchase requests along with a status of said purchase requests, said purchase request management 
screen further including a task assignment option permitting assignment of a purchase request to an indiviouaJ 
salesperson when selected by the dealer. 
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